Subject: Issues in latest spec (NetBIOS etc)

From: [email-masked] (Paul Brittain)
Date: Wed, 3 Aug 94 18:30:11 BST

Connect Riglet:

I have some comments arising from the latest DLS spec and mails posted while I
have been on vacation (over 400K in total - took some reading!).  There are
several smaller issues, and a larger issue on NetBIOS_ex/cs messages that I see
has already provoked some discussion on the net.  I have tried to pull together
the output from discussions here at DLC with the postings while I have been
away to give an overall picture of the NetBIOS issues.  Hopefully this will
enable us to come to a conclusion relatively quickly for incorporation in
Alan's next release of the spec.

                             =============
                       >>>>>>  IMPORTANT  <<<<<<
                             =============

If you only have time to skim this mail quickly, please read the following
section as it summarises the root cause of several potential issues in NetBIOS
support.  If possible, read the rest too though!
                       -------------------------

NETBIOS CIRCUIT SETUP
=====================

Section 4.1.1. documents a Netbios connect flow that uses NQ/NR_ex
messages to locate a name AND (IMPLICITLY) TO EXCHANGE NETBIOS SESSION
NUMBERS.

The implied action has two consequences:

-        The NQ_ex should ALWAYS cause a NAME_QUERY to flow on the LAN
         and cannot be replied to from cache (unless it is part of a
         FIND.NAME request and has a zero session number)

         (This is also the key to supporting multiple NetBIOS sesisons
          between the same MAC addresses.  If the NQ_ex always causes the
          session number to be propagated on the LAN, multiple sessions
          will work without any need for NQ_cs messages.  See Thang Do's
          note on this subject)

-        If this really is the flow we intend to use, should we
         document the NQ/NR_cs messages in the FSM as they will not
         be used?

There are two corresponding parts to the potential solutions to this
issue:

-        Either we document an 'explorer FSM' that specifically
         disallows replies to NQ_ex requests from cache (apart from
         FIND.NAME operations), or we adopt the convention that
         FIND.NAME requests correspond to _ex messages, and session
         setup attempts correspond to _cs messages.

-        Also we need to remove the references to NQ/NR_cs messages in the
         FSM, or we must change the flow in 4.1.1. to use NQ_cs instead
         of the NQ_ex.  (I am, for now, ignoring any desire to keep the NQ_cs
         messages for back-compatability as that is independent of this
         discussion)

My preference is to preserve the flow of 4.1.1, and to document the
explorer FSM and main FSMs to remove NQ/NR_cs messages.
Obviously such messages will still be required if you want to talk
to a back-level DLSw, but leaving them in here leads to confusion
over the main FSM that defines the DLSw Standard!

However this does mean that all NetBIOS datagrams will be flowing as DATAFRAMEs
instead of DGRMFRAMEs until the SABME flows between the NetBIOS end nodes, so
it is not an entirely clear-cut case.  What do you all think?

Please post your opinions on this issue ASAP so that we can work on documenting
the FSMs as everyone would like to see them.

(End of the IMPORTANT bit for those who are pressed for time.)

EXPLORER FSM
============

The documentation of the *_ex messages seems insufficient to guarantee that
everyone interprets them in the same way.  The best way to avoid confusion
would be to define an 'explorer FSM' to handle these messages.  This could be
incorporated into the main FSM if desired as the process is largely independent
(hence the FSM merge is easy).  Pandian has already issued some FSMs along
these lines, but the NetBIOS issue above makes it unclear whether these are
the right FSMs to use.

In order to clarify the explorer frame processing, I have split out a separate
explorer FSM below.  We can use this to discuss whether the explorer processing
is as intended before deciding whether to merge it back into the main FSM.

In this FSM I have assumed

-       Cache is still optional.

-       Cache entries, if used, should be learnt at every opportunity.

-       A target DLSw may receive CUR/NQ_ex messages from many origin DLSws, so
        there is probably an FSM instance per Data Link ID/Origin DLSw pair
        (c.f. circuits where it is just per Data Link ID).  I have made no
        assumption about how this would be implemented.

-       Local retries of frames are absorbed/generated by a mechanism outside
        the scope of this FSM.

The states in the explorer FSM are:

RESET           -       initial state
SENT_EX         -       Sent an explorer frame
RECEIVED_EX     -       Received an explorer frame.
SENT_REC_EX     -       Sent and received explorer frame for same circuit
                        (For correct exchange of NetBIOS session numbers)

DLC events are as per the main FSM.

    RESET State:

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive CANUREACH_ex | If replying from    | If DLC_START_DL sent,|
    |                      | cache, send         |   RECEIVED_EX        |
    |                      | ICANREACH_ex        |                      |
    |                      | else if allowed to  |                      |
    |                      | test availability,  |                      |
    |                      | issue DLC_START_DL. |                      |
    |                      | Optionally update   |                      |
    |                      | cache.              |                      |
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex | Optionally update   | RESET                |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache.              |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| Optionally update   | RESET                |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVE_C        | Send CANUREACH_ex   | SENT_EX              |
    | (i.e. not a frame    |                     |                      |
    |  that starts a circ.)|                     |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
    +----------------------+---------------------+----------------------+

    SENT_EX State:

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive CANUREACH_ex | Send ICANREACH_ex   | RESET                |
    | (for same circuit in | DLC_RESOLVE_R       |                      |
    |  opposite direction) | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex | DLC_RESOLVE_R       | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RSP)  | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVE_C        |                     | SENT_EX              |
    | (i.e. not a frame    |                     |                      |
    |  that starts a circ.)|                     |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_EX              |
    | (different session   | Optionally update   |                      |
    |  number)             | cache               |                      |
    +----------------------+---------------------+----------------------+

    RECEIVED_EX State:

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive CANUREACH_ex | Optionally update   | RECEIVED_EX          |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive ICANREACH_ex |                     | RECEIVED_EX          |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex|                     | RECEIVED_EX          |
    +----------------------+---------------------+----------------------+
    | DLC_DL_STARTED       | Send ICANREACH_ex   | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_RESOLVE_C        | Send ICANREACH_ex   | RESET                |
    | (opposite direction) | DLC_RESOLVE_R       |                      |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_RSP)  | Send NETBIOS_NR_ex  | RESET                |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+

    SENT_REC_EX State:

    +----------------------+---------------------+----------------------+
    |        Event         |      Action(s)      |      Next State      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RSP)  | RECEIVED_EX          |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex  | SENT_REC_EX          |
    | (different session   | Optionally update   |                      |
    |  number)             | cache               |                      |
    +----------------------+---------------------+----------------------+
    | DLC_DGRM (NAME_RSP)  | Send NETBIOS_NR_ex  | SENT_EX              |
    |                      | Optionally update   |                      |
    |                      | cache               |                      |
    +----------------------+---------------------+----------------------+

Please post your opinions on whether this FSM appears correct, especially
with respect to NetBIOS session number exchanges.  We can then worry about how
to merge this with the main FSM.

SPEC COMMENTS
=============

Finally, a few smaller comments on the latest spec.  All have already been
passed to Alan, but they have some level of implied functional change that
you should all take this opportunity to comment on.

Page 9:

   (EDITOR's Note: I ONLY COUNT 70 BYTES, IS 72 CORRECT AND DO I NEED TO SHOW
   ADDITION RESERVED BYTES AT THE END???)
PJB>* Please add the 2 reserved bytes

Page 13:

   .......        Upon receipt, the origin DLS starts a data link and returns
   Origin Circuit ID to the target DLS within the REACH_ACK message.  If the
   REACH_ACK message is not successfully received, the target Data Link Switch can
   obtain the Origin Circuit ID from a subsequent message (i.e., CONTACT,
   XIDFRAME, or DGRMFRAME).
PJB>*  I believe that the REACH_ACK 'loss' problem discussed here should not
PJB>*  occur with the current FSMs (because of better handling of crossover XID
PJB>*  cases and NetBIOS).  Hence a real lost REACH_ACK is just one example of
PJB>*  all the problems that an unreliable transport would give the current
PJB>*  FSMs, so I see no point in singling it out.  We should drop the
PJB>*  requirement that a DLSw handle this one case of the general problem.
PJB>*  (and hence delete the last sentence above).

Page 17:

   The following table lists the protocol data units that are exchanged between
   Data Link Switches.  All values not listed are reserved for potential use in
   follow-on releases.

    Command            Function                            Type     flags
    -------            --------                           -------   -----
3   CANUREACH_ex       Can U Reach Station-explorer        x'03'    SSPex
3   CANUREACH_cs       Can U Reach Station-circuit start   x'03'
3   ICANREACH_ex       I Can Reach Station-explorer        x'04'    SSPex
3   ICANREACH_cs       I Can Reach Station-circuit start   x'04'
    REACH_ACK          Reach Acknowledgment                x'05'
    DGRMFRAME          Datagram Frame (see Note 1)         x'06'
    XIDFRAME           XID Frame                           x'07'
    CONTACT            Contact Remote Station              x'08'
    CONTACTED          Remote Station Contacted            x'09'
    RESTART_DL         Restart Data Link                   x'10'
    DL_RESTARTED       Data Link Restarted                 x'11'
3   ENTER_BUSY         Enter Busy (see Note 2)             x'0C'
3   EXIT_BUSY          Exit Busy (see Note 2)              x'0D'
    INFOFRAME          Information (I) Frame               x'0A'
    HALT_DL            Halt Data Link                      x'0E'
    DL_HALTED          Data Link Halted                    x'0F'
3   NETBIOS_NQ_ex      NETBIOS Name Query-explorer         x'12'    SSPex
3   NETBIOS_NQ_cs      NETBIOS Name Query-circuit setup    x'12'
PJB>*                                                            ^ (see note 3)
3   NETBIOS_NR_ex      NETBIOS Name Recognized-explorer    x'13'    SSPex
3   NETBIOS_NR_cs      NETBIOS Name Recog.-circuit setup   x'13'
PJB>*                                                            ^ (see note 3)
    DATAFRAME          Data Frame (see Note 1)             x'14'
1   HALT_DL_NOACK      Halt Data Link with no Ack          x'19'
    NETBIOS_ANQ        NETBIOS Add Name Query              x'1A'
    NETBIOS_ANR        NETBIOS Add Name Response           x'1B'
    CAPABILITES_EX     Capabilities Exchange               x'20'
    IFCM               Independant Flow Control Message    x'21'
1   TEST_CIRCUIT_REQ   Test Circuit Request                x'7A'
1   TEST_CIRCUIT_RSP   Test Circuit Response               x'7B'

3   Note 1: Both the DGRMFRAME and DATAFRAME messages are used to carry
3           information received by the DLC entity within UI frames.
3           The DGRMFRAME message is addressed according to a pair of
3           Circuit IDs, while the DATAFRAME message is addressed
3           according to a Data Link ID, being composed of a pair of MAC
3           addresses and a pair of link SAP addresses.  The latter is
3           employed prior to the establishment of an end-to-end circuit
3           when Circuit IDs have yet to be established or during circuit
3           restart when Data Links are reset.
3
3   Note 2: These messages are not used for the DLSw Standard but may
3           be used by older DLSw implementations.  They are listed
3           here for informational purposes.  These messages were added after
            publication of RFC 1434 and were deleted in this standard

PJB>*  I think the NetBIOS suport in the FSM is a little confused at present.
PJB>*  I will post a more detailed mail to the connect RIGlet, but this note
PJB>*  will still hold true:
PJB>*
PJB>*  Note 3: These messages are not normally issued by a Standard DLSw, which
PJB>*          uses the NB_*_ex messages as shown in section 4.1.1.  However if
PJB>*          a Standard DLSw attempts to interoperate with older DLSw
PJB>*          implementations, these messages correspond to the NETBIOS_NQ and
PJB>*          NETBIOS_NR messages used in RFC1434 both to locate the resource
PJB>*          and to setup a circuit.  This document does not attempt to
PJB>*          provide a complete specification of the use of these messages.

Page 50 - 51:

4.2.2.2 RESOLVE_PENDING State

      +----------------------+---------------------+----------------------+
      |        Event         |      Action(s)      |      Next State      |
      +----------------------+---------------------+----------------------+
      | Receive DATAFRAME    | DLC_DGRM            |                      |
      +----------------------+---------------------+----------------------+
      | DLC_DL_STARTED       | Send ICANREACH      | CIRCUIT_PENDING      |
      +----------------------+---------------------+----------------------+
      | DLC_ERROR            |                     | DISCONNECTED         |
      +----------------------+---------------------+----------------------+
   3  | DLC_DGRM             | Send DATAFRAME      |                      |
      +----------------------+---------------------+----------------------+

PJB>*  This state should also handle the XPORT_FAILURE event - otherwise the
PJB>*  circuit may get to CIRCUIT_PENDING state having ignored such a failure.
PJB>*
PJB>*  I also think that we need Wayne Taylor's proposed change to add LF size
PJB>*  policing logic to this state.

   The RESOLVE_PENDING state is entered upon receipt of a CANUREACH message or a
   NETBIOS_NQ message by the target DLS.  In the former case, a data link is
   started, causing a Test command to be sent by the DLC.  In the later case, a
   NB_Name_Query frame is sent.  This frame is directed to a group MAC address.

   Any CANUREACH messages received in the RESOLVE_PENDING state will be responded
   to if a DLC_DL_STARTED signal is received.  The Data Link Switch may also
   update its topology information based upon the origin MAC address information
   in each CANUREACH message.

   Upon the receipt of a DLC_DL_STARTED signal in the RESOLVE_PENDING state, the
   Data Link Switch may update its topology table base upon the remote MAC address
   information.  The ICANREACH message should be returned to all Data Link
   Switches that had sent a CANUREACH message.  In a similar fashion, the Data
PJB>*
PJB>* The CANUREACH_cs is a circuit setup message.  There should only be one
PJB>* such message received by any one target DLSw since the CANUREACH_ex
PJB>* exchange identifies the correct DLS partner.  Hence there is no need to
PJB>* maintain a list of partners that sent us a CANUREACH_cs as there will be
PJB>* only one.
PJB>*
PJB>* The previous sentence should therefore be deleted.

   Link Switch may update its topology table upon the receipt of a
   NB_Name_Recognized frame and a NETBIOS_NR message will be returned to all Data
   Link Switches that have sent a NETBIOS_NQ message.

PJB>*  Ditto for NETBIOS_NQ_cs messages (if they survive).  This would not hold
PJB>*  for NQ_ex mesages though.

   The RESOLVE_PENDING state is exited once the data link has been started (i.e.,
   a DLC_DL_STARTED signal is received as a result of a Test response received by
   the DLC) or a NB_Name_Recognized frame is received (i.e., a DLC_DGRM signal is
   received).  The target Data Link Switch will then enter the CIRCUIT_PENDING
   state.

     Note:  Some implentations will also send a Test command in order to start the
     data link to the station that responded to the Name Query frame (i.e., a
     DLC_START_DL will be issued).

Page 52:

4.2.2.3. CIRCUIT_START State
   3
   3  +----------------------+---------------------+----------------------+
   3  |        Event         |      Action(s)      |      Next State      |
   3  +----------------------+---------------------+----------------------+
   3  | Receive CANUREACH_cs | If origin MAC addr  | If DLC_START_DL      |
   3  | for circuit in       | in CANUREACH_cs is  | issued:              |
   3  | opposite direction   | greater than origin |   RESOLVE_PENDING    |
   3  |                      | MAC addr of circuit:|                      |
   3  |                      |   DLC_START_DL      |                      |
   3  |                      | else:               |                      |
   3  |                      |   no action taken   |                      |
   3  +----------------------+---------------------+----------------------+
   3  | Receive ICANREACH_cs | Send REACH_ACK,     | If Connected:        |
   3  |                      | If Connected:       |  CONNECT_PENDING,    |
   3  |                      |  Send CONTACT       | else:                |
   3  |                      | else:               |  CIRCUIT_ESTABLISHED |
   3  |                      |  no action taken    |                      |
   3  |                      |                     |                      |
   3  +----------------------+---------------------+----------------------+
   3  | DLC_DGRM             | Send DATAFRAME      |                      |
   3  +----------------------+---------------------+----------------------+
   3  | CS_TIMER_EXP         |                     | DISCONNECTED         |
   3  +----------------------+---------------------+----------------------+

PJB>*  This table requires the XPORT_FAILURE event too.
PJB>*
PJB>*  I also think that we need Wayne Taylor's proposed change to add LF size
PJB>*  policing logic to this state.

Page 58:

4.2.2.9 CIRCUIT_RESTART State

      +----------------------+---------------------+----------------------+
      |        Event         |      Action(s)      |      Next State      |
      +----------------------+---------------------+----------------------+
      | Receive DL_RESTARTED | If Connected:       | If Connected:        |
      |                      |  Send CONTACT       |  CONNECT_PENDING,    |
      |                      |                     | else:                |
      |                      |                     |  CIRCUIT_ESTABLISHED |
      +----------------------+---------------------+----------------------+
   1  | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
      +----------------------+---------------------+----------------------+
      | Receive DATAFRAME    | DLC_DGRM            |                      |
      +----------------------+---------------------+----------------------+
      | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
      +----------------------+---------------------+----------------------+
      | DLC_DGRM             | Send DATAFRAME      |                      |
      +----------------------+---------------------+----------------------+
   3  | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
      +----------------------+---------------------+----------------------+

   The CIRCUIT_RESTART state is entered if a DLC_RESET signal is received from the
   local DLC.  This was caused by the receipt of a SABME command while a
   connection was currently active.  A DM response will be issued to the SABME
   command and the Data Link Switch will attempt to restart the end-to- end
   circuit.

PJB>*  Surely a DGRMFRAME would be more sensible to use in this state as we
PJB>*  still have the circuit correlators needed for this message.
PJB>*
PJB>*  (Apologies if I have asked this before and forgotten the result - I am
PJB>*   concentrating on getting a comprehensive set of comments for discussion
PJB>*   at this point).

Page 60:

4.2.2.11. RESTART_PENDING State

      +----------------------+---------------------+----------------------+
      |        Event         |      Action(s)      |      Next State      |
      +----------------------+---------------------+----------------------+
   1  | Receive HALT_DL_NOACK|                     | HALT_PENDING_NOACK   |
      +----------------------+---------------------+----------------------+
      | Receive DATAFRAME    | DLC_DGRM            |                      |
      +----------------------+---------------------+----------------------+
      | DLC_DL_HALTED        | Send DL_RESTARTED   | CIRCUIT_ESTABLISHED  |
      +----------------------+---------------------+----------------------+
      | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
      +----------------------+---------------------+----------------------+
      | DLC_DGRM             | Send DATAFRAME      |                      |
      +----------------------+---------------------+----------------------+
   3  | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
      +----------------------+---------------------+----------------------+

PJB>*  As before, isn't a DGRMFRAME more sensible to use in this state as we
PJB>*  still have the circuit correlators needed for this message?
PJB>*

                      -------------------------------------

That seems to be more than enough for one mail!  I still need to re-read some
of the mails posted while I was on vacation and return more detailed responses,
but the most important issues are all described above.

Paul Brittain
Data Connection.

---

From: Lakshman Garikapaty <[email-masked]>
Date: Fri, 5 Aug 94 11:08:38 EDT

>to merge this with the main FSM.
   
Well i have done an exhaustive rework on the FSM and sent to the group 
last week which covers both the explorer and regular messages. Please
read that fsm and don't try to reinvent the wheel. If there are any
glaring problems to that fsm we can corret them. I must confess i am not an 
expert in netbios exchange, but i think the fsm that i provided will
solve, if not we can correct that fsm.

>PJB>* exchange identifies the correct DLS partner.  Hence there is no need to

I think an implementation can have, thru management, static entries on where
the remote parnters are located. In this case there is no need to send
canureach_ex messages instead can send canureach_cs directly. In this case
maybe we need to update the list?

Hope this helps.

Lakshman.